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(54) Methods and systems for collateral matching and mark to market reconcilement 

(57) The present invention provides secure, high- 
volume, processing methods and systems for multiple 
financial instruments that combine collateral matching 
to identify matched and unmatched financial transac- 
tions and consolidated mark to market valuations for all 
parties to a nriatched financial tTEinsaction. Further, the 
methods and systenns of the present invention: (1) pro- 
vide real-time identification of matched and unmatched 
financial transactions; (2) provide real-time mark to mar- 
ket portfolio valuations; (3) provide standard formulae 
and user preferences to develop algorithms for real-time 
mark to market portfolio valuations; (4) accommoc^te 
additional financial instruments and additional users; (5) 
minimize manual review of discrepancies in margin val- 
uations; (6) provide multilingual capabilities, settiement 
cun'endes, and other identifiers necessary to communi- 
cate the results of collateral matching and mark to mar- 
ket portfolio valuations; (7) factlttate lower financial 
transaction and processing costs; and (8) minimize the 
manual entry and re-keying of information into multiple 

formats and templates used parties to a financial trans- - - 

action. 

In other embodiments of the present invention, the 
methods and systems may be designed to: (1 ) utiftze a 
user-friendly interactive user interface; (2) provide inte- 
gration with external and internal systems; (3) provide 
detailed reports; (4) allow for real-time system modifica- 
tions and system configuration; (5) altow for customized 
import/export files; and/or (6) utilize state-of-the-art 
communications technology. 
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Description . ^. 
PRIORriY APPLICATION 

[0001] This application claims the benefit of US 5 
Provisional Application No. 60/146,569 filed July 30, 
1 999, entitled 'System and Method for Mark to Market 
Reconcilement,' and is incorporated herein by refer- 
ence. 
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COPYRIGHT NOTIFICATION 

[0002] A portion of the disclosure of this patent doc- 
ument and its figures corrtain material that is subject to 
copyright protection. The copyright owner has no objec- is 
tion to the facsimile reproduction by anyone of the pat- 
ent document or the patent disclosure, as it appears in 
the Patent and Trademark Office patent files or records, 
but othenwise reserves all copyrights whatsoever. 
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BACKGROUND OF THE INVENTION 

1 ■ Reld of the Invention 

[0003] The present invention relates generally to 25 
the field of collateral matching and mark to market rec- 
oncilement that allows parties to a financial transaction 
to easily, effidentty, and reliably manage the margining 
process. More particularly, the present invention pro- 
vides secure, high-volume processing methods and 30 
systenr^ for multiple financial instruments that combine 
collateral matching to identify matched and unmatched 
finandal transactions and consolidated marie to market 
valuations for all parties to a matched financial transac- 
tion. 35 

2. Background 

[0004] RnarK;ial market partbipants are constantly 
aware of the risks and opportunities in the dynamk^s of 40 
the foreign exchange, derivatives market, and securities 
market. Bilateral margin agreements are dynamic mar- 
ket contracts in whfch the parties must account for the 
margin, the variance in value between the contract price 
and the market price. Subject to market fluctuations, the 45 
valuation of the margin by each party is often a source 
of conflict and tremendous mari<et ineffidency. Whether 
it is the complexity and volume of the transactions 
between the parties, the use of different formulae to cal- 
culate the value of the ti^nsactions, or a combination of so 
the above factors, the disconnect in margin valuation 
demands a time consuming manual review process that 
is detail-oriented and ennor prone. Manually reviewing a 
difference or discrepancy in the margin valuation keeps 
the parties from adequately and pronrtptty assessing its 55 
business risks and opportunities in a rapidly changing 
market economy. 

[0005] Bilateral margin agreements require each 
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party to bear a high level of risk in dealing with the other. . 
The variance of the market and its effect on ttie margin 
valuation can create various incentives for a party to 
take advantage of a favorable market or to remain inac- 
tive. The risk is in the part/s mari< to market valuation of 
the margin and in the varying market valuation of collat- 
eral agreements. Derivative instruments, such as, an 
interest rate swap, a currency swap, or an interest rate 
option, pose the greatest risk valuations because they 
are based on changes in terms of notional amounts and 
not on exact values. 

[0006] Typk^ly, a major party, A, such as any m^or 
global financial institution or tenk, has a significant 
book (portfolio) of transactions. For example, a particu- 
lar global bank may have anywhere from one to fifty (50) 
transactions against a counter-party, B. Those transac- . - 
tions might be booked and they might all be confirmed, 
but they are for different notional values, different peri- 
ods of time, and, in fact, some of them may be interest 
rate swaps and some of them may be currency swaps. 
Such a portfolio of transactions raises a significant 
number of risk issues. 

[0007] One of the risk issues, for example, is the 
mark to market value of a partcular transaction. For 
example, the interest rate swap transaction that lasts 
over an eighteen (18) month period has an initial value 
at finandal transaction date. However, because time 
passes and there is a timed value of money, the value of 
that transaction changes every c^. It changes based 
on how interest rates change, whk:h is the floating side; 
it changes based on exactiy how time passes; and it 
also changes based on factors involved with the volatil- 
ity of interest rates. 

[0008] The changes can be cak^ulated using, for 
example, complicated mathematical formulae, but the 
important factor is that the value of the transaction 
behween A and B is different every day. In a portfolio of 
transactions, let us say fifty (50) transactions, for differ- 
ent values between A and B, some of these transactions 
can be in the nrroney and some of them can be out of the 
money to eittier party. Generally, these values are net- 
ted because the parties have netting agreements estab- 
lished between them. However, the problem remains 
that it is most likely that one party is going to be net out 
of the money with the other party. 
[0009] Assume, for example, that we have fifty (50) 
transactions in this portfolio between A and B, and that 
B is $2 million out of the money as of a given day, such 
as today. This means that A has at least $2 million of 
pure, economy risk that if B, for example, becomes 
bankrupt today, A will not receive these moneys. There- 
fore, the institution of collateral agreements has become 
commonplace within the marketplace. 
[0010] A collateral agreenrtent means that, based 
on certain parameters, if B is out of the money, such as 
$2 million, B will post an agreed upon amount of collat- 
eral to be held by A until the maricet changes. The mar- 
ket changes every day, and rather than going through 
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the Jaborious^and . inefficient process of margin-call, B 
sends A collateral, a smaller sum of money, such as, 
$50,000.00. In other words, until the market changes 
$50,000.00 back in B's favor, A would keep the collat- 
eral. Collateral agreements make sense in continuing 
business relationships because the changing market 
conditions make it unreasonable to constantly move 
money between parties when one party's gains on one 
day may be losses on the next 
[0011] Given the improved efficiencies of collateral 
agreements over margin-calls, there are still ineffk^ten- 
cies in their use. For example, the amount of collateral 
must be agreed upon and must be delivered to the 
proper party. Additionally, the timely movement of collat- 
eral t)etween parties can be a source of ineffidency if 
the parties are unable to agree upon the amount consti- 
tuting collateral. Further, the differerice in how parties 
mark to market the collateral becomes a critical issue. 
[0012] Collateral, such as, a government bond is 
marked to market daily because like any other financial 
instrument, the value of that bond changes every ctey. 
Mark to market is a representation of the daily market 
value and the changes to those market values over a 
period of time. When any A has multiple collateral 
agreements with multiple parties, the portfolio of trans- 
actions typfcally includes a variety of different types of 
transactions, such as, foreign exchange forwards, inter- 
est rate swaps, and cun^ency swaps. Accordingly, there' 
is a myriad of bilateral margin agreements in place. 
[0013] The current process of reconciling these 
types of financial transactions is manually intensive, 
extremely time consuming, and tedious. For example, 
when A and B have 500 transactions, it can take up to 
six monttis just to reconcile those transactions, because 
transactions are maturing and new transactions are 
entered into. Some of the transactions may be rather 
complex and may be under limited control in manual 
spreadsheets. When these transactions are handled on 
a manual basis, the mark to market updates can be 
made on an irregular and unsynchronized schedule, 
thus causing a disparity in the margin valuation and 
ineffbiency incun^d through the review process. At a 
high level of volume, the process becomes untenable, 
inefficient, and error prone. 

[001 4] The ability to reconcile a specific transaction 
that A is valuing and that B is also valuing is further 
affected by the likelihood that the two parties are not 
using exactly the same formulae for creating the value 
of that transaction. Wittiout an established or agreed 
upon standard of formulae for calculating the margin, 
there will always be differences of o|:»nion between A 
and B, although hopefully minor, as to what the value of 
a particular transaction is on any given day. Therefore, 
in addition to agreeing between parties A and B that 
these transacdons exist and that the components of the 
transactions are equal, it is also necessary to mark to 
market the value of a particular transaction from both 
sides on a given day's basis and to reach an agreement 



. on the net value of all transa<Aions. ..... 

[0015] Thus, a need exists for a nnethods and sys- 
tems for remotely accessing a secure communk^tions 
network that provides parties a single point of entry to 
5 electronkjally process collateral matching and mark to 
market valuations of multiple financial instruments in 
numerous financial transaction. A need also exists for 
collateral matching and mark to maricet methods and 
systems that afford basic checks on financial transac- 
10 tion data and that prevents dupricate submission of this 
data. There is a further need for flexible collateral 
matching and mark to maricet methods and systems 
that are able to: (1) provide realtime identification of 
matched and unmatched financial transactions; (2) pro- 
fs vide real-time mark to market portfolio valuations; (3) 
provide standard formulae and user preferences to 
develop algorithms for real-time mark to market portfolio 
valuations; (4) minimize manual review of discrepancies 
in margin valuations; (5) accommodate additional finan- 
20 dal instruments and additional users as the system 
expands; (6) fadlrtate lower finandal transaction and 
processing costs; (7) provide multilingual capabilities, 
settiement currencies, and other identifiers necessary 
to globally communk^te with users interested in collat- 
25 eral matching and mark to market portfolio valuations; 
and (8) minimize the manual entry and re-keying of 
information into multiple formats and templates used by 
parties to a financial transaction. 

30 SUMMARY OF THE INVENTION 

[0016] To overcome the aforementioned problenns, 
the present invention provides an easy, efficient, and 
reliable standard for parties to effidentty, accurately, and 

35 immediately evaluate its relative market positions by 
providing methods and systems for collateral matching 
and mark to nnarket valuations of multiple financial 
transactiona The system utilizes computer hardware 
and software and makes use of a number of key compo- 

40 nents, such as a data translation engine, a matching 
and reconciliation engine with bilateral capabilities, and 
a dient-side reporting administration system using web- 
based technology. In a secure interface via encrypted 
and authenticated file transfers, the methods and sys- 

45 tems for an embodiment of the present invention enable 
any execution confirmation matching system to feed the 
results of a matched transaction to the mark to market 
■* recondlement system to collaterally match and to 
derive mark to market valuations: 

50 [0017] In an embodiment of the present invention, 
financial transaction data is transmitted using web- 
based technology or using a computer-to-computer 
interface (e.g., a direct link to a broker's order capture 
system). The finandal transaction data transmitted by a 

55 party is formatted to FIX, SWIFT, or another standard 
eleclronk: format Once in a standard fbrniat, the trans- 
action data is transmitted and stored to a communfca- 
tions network that any party can access to track the 
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status of the collateral matching and mark to market val- 
uations and to report on exception items. 
[0018] tn an embodiment of the present Invention, 
the methods and systems consist of one or more cfient 
terminals that works in conjunction with a communica- s 
tions network(s). network server(s), and database(s). 
The client terminal is an interactive electronic communi- 
cations device, such as, for example, PCs and/or serv- 
ers running UNIX or LINUX, a Macintosh, a personal 
digital assistant (PDA), a pen-based computer, an inter- io 
active pager, mobile and cellular phones, a WAP phone, 
an interactive television, and the like. The client temiinal 
gets all the data it needs to display 'user modules' that 
represent screens displayed on a client temninal and 
allows a user to view, input, select, and/or transmit 75 
financial transaction data, including user instructional . 
data. For example, instead of a party manually review- 
ing portfolio accounts to determine matched financial 
transaction and mark to market valuations, financial 
transaction data is transmitted in an electronic transfer 20 
medium, such as, an interactive web-page. The finan- 
cial data standardized, verified, stored, identified as 
matched, unmatched, or marked as an exception. 
Thereafter, mark to market valuations of the transaction 
data are automatically performed using algorithms of 25 
standard formulae and user instructions. 
[0019] In an embodiment of the methods and sys- 
tems of the present invention, web-browser/web-server 
technology can be used in a GUI application to gener- 
ate, access, and download client reports, and act as an 30 
administrative interface. The web-browser is used to 
deliver a cfient report to provide the following informa- 
tion: total mark to market valuation, matched financial 
transactions, unmatched financial transactions, import 
errors, and other infomnation as required. In an embod- 35 
imertt of the present invention, the web-browser further 
enables users to generate and transmit administrative 
instructions for file transfer. The user is able to link and 
unlink financial transactions, manually match and 
unmatch financial transactions, add or amend product 40 
codes and parties, upload financial transaction data 
files, download results data, and manage other adminis- 
trative portfolio tasks. 

[0020] In an embodiment of the methods and sys- 
tems of the present invention, a server skie data trans- 45 
lation engine can translate a party's financial 
transaction data into a standardized format through 
data parsing, validation, and format conversion. All file ' 
imports are logged and time-stamped in order to pro- 
vide a complete history and audit trail. Any enors so 
encountered in the import process are logged and writ- 
ten into a database unless primary key data is missing. 
In another embodiment, this engine offers the flexibility 
of creating new import specifications and modifying 
existing ones in order to accommodate new file formats 55 
and changes in data content 

[0021] In an embodiment of the present invention, 
the data translation engine feeds the standardized data 



, to a separate server side engine with.bilateraLcapabili-,^ 
ties to match and reconcile financial transactions. This 
matching and reconciliation engine updates existing 
financial transac^ons and inserts any new financial 
transactions. Specifically, existing unmatched financial 
transactions are updated with the latest data and exist- 
ing matched financial transactions are updated to the 
latest mark to market value. Any other variable fields 
deemed necessary are also be updated. The system 
then attempts to match any new financial transactions 
that have arrived. On a periodk: basis set by the user, 
the system will carry out the reconciliation process for 
all matched finandal transactions that have been 
updated in the previous period. 
[0022] In anotiier embodiment of the invention, soft- 
ware encryption and authentication is accomplished 
using something akin to the concept of having public 
and private keys. The security system generates a pair 
of linked keys ~ one of which is public and the other is 
private. The public key is used to generate an encrypted 
file and can only be decrypted by using the private key. 
The public key is thus distributed by a party to another 
party (e.g., counter-party) that it wishes to exchange 
encrypted data. 

[0023] In addition to providing the methods and sys- 
tems outiined above, the present invention: (1) provides 
highly configurable data import/export specifications; 
(2) standardizes data formats data; (3) fadlitates auto- 
matic file transfer; (4) provides near real-time marie to 
market comparisons of selected financial transaction 
valuations; (5) allows a user to define dedsion making 
criteria to recondle the mark to market value of 
matched transactions; and/or (6) notifies each party of 
new finandal transactions. 

[0024] In another embodiment of the present inven- 
tion, the methods and systems may be utilized to per- 
form one or more, of the following tasks: (1) utilize a 
user-friendly interactive user interface; (2) provide inte- 
gration with external and internal systems; (3) provide 
detailed reports; (4) allow for real-time system modifica- 
tions and system configuration; (5) allow for customized 
import/export files; and/or (6) utilize state-of-the-art 
communications technology. 

[0025] Furttier details on these embodiments, other 
possible emfc>odiments, and additional methods and 
systems of the present invention are set forth below. 
[0026] As are appreciated by those of ordinary skill 
in the art, the methckls and systems of the* present 
Invention have wide utility in a number of areas as illus- 
trated by the wide variety of features and advantages 
discussed below. 

[0027] It is a feature and advantage of the present 
invention to provide methods and systenns of automati- 
cally collecting and distributing collateral marie to maricet 
valuation recondlement information associated with a 
financial transaction that provide real-time notification of 
all valuation changes to parties to a finandal transac- 
tion. 
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[0028] It is .another feature, and. advantage of the . 
present invention to provide methods and systems for 
automated collateral matching and mark to nrtarket rec- 
oncilement with a globaJ reach that reduces manual 
activity, expands productivrty. and acts as a bridge to 5 
both confirmation and depository systems. 
[0029] It is another feature and advantage of the 
present invention to import and store financial transac- 
tion data feeds by remote booking/accounting systems 
and to allow all parties to a transaction to be aware of a ro 
new transaction whenever the transaction is uploaded. 
[0030] It is another feature and advantage of the 
present invention to access, convert, manage, store, 
and transmit electron'c financial transactional data 
associated with collateral matching and mark to market 75 
valuations. 

[0031] It is another feature and advantage of the 
present invention to enable parties in a transaction to 
establish norms and other reconcilement criteria, and, 
to thereby, monitor mark to market values with more 20 
certainty. 

[0032] It is another feature and advantage of the 
present invention to allow the use of different reconcile- 
ment algorithms or sets of algorithms among parties to 
a financial transaction. 25 
[0033] It is another feature and advantage of the 
present irtvention to evaluate data fields in a financial 
transaction and to match financial transactions based 
on data tolerances and/or user preferences. 
[0034] It is another feature and advantage of the 30 
present invention to evaluate date fields in a financial 
transaction and to match financial transactions based 
on date tolerances and/or user preferences. 
[0035] It is another feature and advantage of the 
present invention to evaluate number fields in financial 35 
transaction data and match transactions based on 
number tolerances and/or user preferences. 
[0036] It is another feature and advantage of the 
present invention to reduce costly exception processing 
associated with collateral matching and mark to maricet 40 
valuations. 

[0037] It is another feature and advantage of the 
present invention to generate key financial reports that a 
party can use to monitor and control portfolios of collat- 
erafized agreements and other bilateral margin agree- 45 
ments. 

[0038] It is another feature and advantage of the 
present invention to eliminate the need for customers 
using a depository or collateral agent to re-key cteily 
data. so 
[0039] It is another feature and advantage of the 
present invention to make file hand-offs automatic. 
[0040] It is another feature and advantage of the 
present invention to convert data into a standardized 
format 55 
[0041] It is another feature and advantage of the 
present invention to provide flexible data conversion 
parameters. 



[0042] It is another feature and advantage of the. 
present invention to authenftcate, verify, and confirm 
mark to market parameters and finandal transaction 
data to recondle matched financial transactions. 
[0043] It is another feature and advantage of the 
present invention to automatically export finandaJ trans- 
actional data to multiple users, including buyers, sellers, 
and third parties (e.g., collateral agents, depositories, 
etc.). 

[0044] It is another feature and advantage of the 
present invention to provide detailed audit reports to 
capture the actions, events, enors, and the like invoh^d 
in the import and/or export of data, in the intemal 
processing of data, and in the manual matching and 
reconcilement processes. 

[0045] It is another feature and advantage of the 
present invention to provide security, authentication, 
and entitiement features. 

[0046] It is another feature and advantage of the 
present invention to allow a party to enter and submit 
financial transaction data and to modify previously sub- 
mitted financial transaction data. 
[0047] It is another feature and advantage of the 
present invention to provide a flexible collateral match- 
ing and mark to market system that is capable of 
accommodating changes in the system architecture. 
[0048] It is another feature and advantage of the 
present invention to accommodate growth in the 
number of users (e.g., parties, system administrators, 
etc.). 

[0049] It is another feature and advantage of the 
present invention to provide a collateral matching and 
mark to market system that is capable of running on 
many different hardware platfonro and with many differ- 
ent operating systems. 

[0050] It is another feature and advantage of the 
present invention to Interface and communk:ate with the 
network communications system through a variety of 
electronic mediums, including wireline and wireless 
technology, such as, for example, WAN, LAN, PSTN, 
pubric networics, satellite systems, and the like. 
[0051] It is another feature and advantage of the 
present invention to provide on-line system help to the 
user. 

[0052] It is another feature and advantage of the 
present invention to provide for multiple levels of user 
access and to facilitate multiple levels of security related 
to those levels of user access. 
[0053] It is another feature and advantage of the 
present invention to secure the source code on the net- 
work server and/or conamunications network. 
[0054] It is another feature and advantage of the 
present invention to provide a user witii access to a vari- 
ety of optional additional useful administrative features, 
such as, for example, changing a password, adding a 
financial instrument, and setting defaults. 
[0055] It is another feature and advantage of the 
present invention to have one standardized user inter- 
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face regardless of a user's computer systerri (i.e., the. 
hardware platforms, operating systems, programming 
languages, software applications, and other computer 
technology). 

[0056] It is another feature and advantage of the s 
present invention to allow a user to store data on a local 
computer or local network. 

[0057] It is another feature and advantage of the 
present invention to provide multilingual capabifrties 
including translations of financial transaction data, to 
including mark to market data and user data. 
[0058] It is another feature and advantage of the 
present invention to allow a user to select a language 
(e.g., English, French, Spanish, German, etc.) to display 
user module information, including data that is uploaded is 
.or downloaded by a user. 

[0059] It is another feature and advantage of the 
present invention to allow for single data entry in order 
to eliminate the mistakes caused by the re-entry of cteta 
by multiple users, and accordingly, to reduce the need 20 
for personnel to enter financial transaction data and rec- 
oncilement data. 

[0060] It is another feature and advantage of the 
present invention to significantly reduce the time 
required by the overall reconcilement process. 25 
[0061] These advantages and features may be 
accomplished singularly, or in combination, in one or 
more of the embodiments of the present invention. 
[0062] Additional uses, objects, advantages, and 
novel features of the invention are set forth in the 30 
detailed description that follows and will become more 
apparent to those skilled in the art upon examination of 
the following or upon learning by practice of the inven- 
tion. 

35 

BRIEF DESCRIPTION OF THE FIGURES 

[0063] Other advantages and features of the inven- 
tion are more dearly understood by reference to the fol- 
lowing description taken in connection with the 40 
accompanying figures, in which: 

Rgures 1A, entitled "MTM Recondlement Topology 
Overview," and IB, entitied "MTM Reconcilement 
System Schematic," illustrate overviews of the rec- 45 
oncilement topology and system schematic in one 
or more embodiments of the methods and systenns 
for collateral matching and mark to market reconcil- 
iation. 

Rgure 2, entitied "Overview - Mark to Market Valu- so 
ation," illustrates an overview of the mark to market 
valuation process flow in an embodiment of the 
methods and systems for collateral matching and 
mark to market reconciliation. 

Rgure 3, entitied "Rnancial Transaction Data Row," 55 
illustrates the financial transaction data flows in an 
embodiment of the methods and systems for collat- 
eral matching and mark to market. 
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^ Rgure 4, entitied "Daily Transaction Reconcilement , 
Rows," illustrates the daily process flows in an 
embodiment of the methods and systems for collat- 
eral matching and mark to market 
Rgure 5, entitied "Exposure Summary Report for 
Bank No. 1," illustrates a sample Exposure Sum- 
mary Report in an embodiment of the methods and 
systems for collateral matching and mark to market 
reconciliation. 

Rgures 6A-D, entitled "Data Table for Matched 
Rnancial Transactions," illustrate sample data for 
matched financial transactions in an embodiment of 
the methods and systenris for collateral matching 
and mark to market reconciliation. 
Rgure 7, entitied "Data Table for Unmatched Rnan- 
cial . Tmnsactions," illustrates sample data for 
unmatched financial transactions in an embodiment 
of the methods and systems for collateral matching 
and mark to market reconciliation. 
Rgure 8, entrtied "Data Table for Expired Rnandal 
Transactions," illustrates sample data for expired 
financial transactions in an embodiment of the 
methods and systems for collateral matching and 
mark to market reconciliation. 
Rgure 9, entitled "Import Errors Bank No. 2," illus- 
trates a sample Import Error Report in an embodi- 
ment of the methods and systems for collateral 
matching and mark to market reconciliation. 
Rgure 10, entitied "International Swap Dealer 
Association (ISDA) Agreement Matrix," illustrates a 
sample ISDA agreement matrix in an embodiment 
of the methods and systems for collateral matching 
and mark to market reconciliation. 
Rgure 1 1 , entitled "Sample Input Data RIes - Three 
(3) Types of Input Fomnats," illustrates sample input 
data files in an embodiment of the methods and 
systenr^ for collateral matching and mark to market 
reconciliation. 

Rgures 12A-D, entitied "File Import Specification," 
illustrates samples of file import specifications in an 
embodiment of the methods and systems for collat- 
eral matching and mark to market reconciliation. 
Rgure 13, entitied "Matching Criteria," illustrates 
data tables of matching criteria data fields in an 
embodiment of the methods and systenns for collat- 
eral matching and mark to market reconciliation. 
Rgures 14A and 14B, entitled "Tables of Data 
Relds," illustrate sample tables of data fields in an 
embodiment of the methods and systems for collat- 
eral matching and martc to maricet reconciliation. 

DETAILED DESCRIPTION 

[0064] The essence of the present invention is to 
automate the collateral matching and derivative mark to 
market (MTM) recondlement process by accepting one 
or more files of financial transaction data from numer- 
ous parties and to produce market valuations and 
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reports that enable .each.party in a muttHparty financial 
transaction to agree and adjust its relative collateral 
positions simply and quickly. The present invention is 
related to, but remains independent of, any execution 
confimiation matching system. 5 
[0065] The system reconciles the MTM value of 
multiple financial instruments. Any financial instrument 
(e.g., interest rate swaps, currency swaps, interest rate 
options, non-delivery versions of foreign exchange 
related products, etc.) may be matched and reconciled. 10 
In an embodiment, the present invention reconciles 
matched financial transactions that are handed-off by a 
party such that the financial transaction data can be 
accepted without the need for re-matching. 
[0066] The present invention will now be described is 
in more detail by illustrath^e examples with reference to 
the embodiment(s) depicted in the Rgures. The follow- 
ing described embodiment(s) is presented t>y way of 
example and should not be construed as limiting the 
inventive concept to any particular configuration. 20 
[0067] Refening to Rgures 1A and IB, a basic 
overview of the mark to market (MTM) topology and 
system schematic is depicted. As shown in Rgure 1 , a 
client terminal 101a, 101b or a server 102 is connected 
over a secured firewall 105 to a communications net- 25 
work 160. The communk:ations network 160 includes a 
secured web-server 106, a data parser/translator 107. a 
reports generator 108, a transaction processor 109, and 
a MTM processor 110. Daily MTM values 162, MT^^ 
reports 163, and a web-transactor 161 are maintained 30 
and communk^ated via the communications network. 
Further, the communteations network 160 is coupled 
over a secured firewall 111 to a transaction database 
112 and a database containing customer records 113 
(e.g., records containing profile data of each party, as 
financial servbe provider, etc.). Depositories or other 
third parties 170 may also be connected and have 
access to information in the communk^ations network 
160. Transmission Control ProtocoVlntemet Protocol 
(TCP/IP) 104 may be utilized over a virtual private net- 40 
work wherein a user can dial in through a modem, over 
integrated services digital network (ISDN), or over a 
fixed line, such as, for example, a leased tine to access 
the communications network 160. Altematively, the sys- 
tem operates over the I ntemet using a web-browser 1 03 45 
with suitable bridges and security. 
[0068] The collateral matching and mark to market 
system includes at least one client tenninal 101a, 101b. 
The client terminal 101a, 101b typk^ly includes a cen- 
tral processing unit (CPU), a monitor or other visual dis- so 
play devk:e, a keyboard or some other input devk:e, and 
a communk:a1ions device. Client terminals 101a, 101b 
transmit and receive data to and from a server 106 via a 
communk:ations networic 160. Client temninals 101a, 
101b interact with the server 106 in a typical dii- ss 
ent/server platform. The operation of the system 
according to the embodiment shown in Rgure 1 is as 
follows. A party at a client terminal 101a accesses the 
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■> communications. network and.transmitsiinancial trans- 
action data, including financial data and user pmfile 
data. The server 106 either creates a new object in the 
software or modifies an existing object to standardize 
and store the financial transaction data. Thereafter, the 
financial transaction data is autonriatically matched and 
reconciled using parameters specified by a party A 
counter-party sitting at another client tenninal 1 01 b can 
then enter the system and access the uploaded finan- 
cial transaction data and results including matched 
transactions and mark to market valuations for spedfk; 
finaru^iat instruments. 

[0069] In a possible embodiment of the present 
invention, the client terminal 101a, 101b may be any PC 
running a Windows operating system or may be a Win- 
dows NT workstation with access to a global communi- 
cations network 160, such as, the Intemet For example, 
the client terminal 101a, 101b may be a PC that sup- 
ports either Intemet Explorer or Navigator to provide 
access to the Intranet or Internet. Altematively, it should 
be appreciated that the client terminal 1 01 a, 1 01 b could 
take on a variety of other suitable forms, such as, for 
example, PC's and/or servers running UNIX or LINUX, a 
Macintosh, a PDA, a pen-based computer, an interac- 
tive pager, mobile and cellular phones, a WAP phone, 
an interactive television, and the like. Furthemnore, the 
client tenninal could be electronk:ally connected to a 
communcations network 160 by way of other wireline or 
wireless technology, including, for example, WAN, LAN, 
PSTN, pubric networi(s, satellite systenns, and the like. 
[0070] In an embodiment of the present invention, 
the client tenninal 101a, 101b displays user modules 
that represent screen shots and prompts the user to 
view, input, export, select, and/or transmit various infor- 
mation at>out financial transactions, user information, 
collateral matching criteria, other decision making crite- 
ria, and mark to market valuations. The user modules 
may be advantageously displayed as wet>-page pro- 
jected upon a client terminal 101a, 101b running a web- 
browser 103 coupled with to a communk^ations network 
160. 

[0071] Rgure 2, entitied "Overview - Martc to Market 
Valuation," illustrates an embodiment of the mark-to- 
market process flow between the parties 201, 221 after 
the financial transactions are input and matched 211 
within the system. After each specified period of time, 
usually once daily, ait derivative transactions are 
marked to market 202, 222 by a party 201, 221. Each 
party's formulae may be different and proprietary. As a 
contributing member of the system, each party 201, 221 
runs their proprietary MT^ systenns 202, 222 to value 
their transactions. 

[0072] Then, the results of these MTM bookings 
202, 222 are fed in a known file fomnat 203, 223 to the 
formatting module 210. Botii parties may prepare and 
send their MTM values in different formats. The data is 
then parsed and translated to a standardized fonnat 
210 and transmitted to the MTM processor 21 1 . 
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. [0073].. ..Next..the transactions containing .the. newty 
updated MTM values are matched by the transac^on 
processor 212 against the data contained in the trans- 
action database 213. Thereafter, the current MTM val- 
ues replace the last set of MTM values. This occurs for 
each party that submitted MTM values, including 
revised MTM values. 

[0074] The MTM processor 211 generates the 
reports for each part/s transactions versus those of the 
appropriate counter-party, such that if all parties submit- 
ted revised MTM values, a complete set of valuations for 
each party's portfolio of transactions would result 
[0075] Each party 201 , 221 is able to access the 
reports via a communications network 204, 224 and can 
electronically export the data to be used either as input 
to their own collateral management systenns 205, 225 or 
to the system of the depository 206, 22S managing their 
collateral portfolio. The data may also be printed out in 
a multitude of user specified reports. 
[0076] Rgure 3, entitled 'Rnandal Transaction 
Data Flow,' illustrates the financial transaction data 
flows In an embodiment of the methods and systems for 
collateral matching and mark to market valuation. Note 
that the financial transaction depkrted in Rgure 3 is a 
trade. A party inputs or uploads data files 301 to the 
system and the system parses, maps, translates, and 
enriches the data files into a standard format 302. The 
data files may be used to update and insert financial 
transaction data for unmatched financial transactions 

303, and is then used to match a finandal transaction 

304. Alternatively, the data files may be used to update 
the mark to market value of a matched financial transac- 
tion 304. After a transaction is matched 304, the system 
reconciles the mark to market value and transmits the 
output into a report format 305 that can be output or 
downloaded to a part/s PC or computer infomnation 
system 306. 

[0077] Rgure 4, entitled "Daily Transaction Recon- 
cilement Rows,* further illustrates the daily transaction 
reconcilement flows In an embodiment of the methods 
and systems for collateral matching and mark to market 
A party exports data to a standard fomnat 401 whk:h is 
encrypted using pubrtc key and other security precau- 
tions 402. Thereafter, the data is transmitted to a server 
403, and the "transaction" process begins. The data is 
monitored on the server 410 and translated and copied 
to a data file 41 1 . The data file is decrypted and authen- 
ticated 412, and then inriported, updated, and matched 
with other financial transaction data 413. The system 
runs a reconcilement process 420 for the matched 
transactions and exports the results to each party in an 
encrypted format 421. A party can access the server 
440 and receive the results of the matching and the 
mark to market reconcilement process. The server or 
software running on the part/s local computer system 
decrypts and authenticates the results 441 and imports 
the results to the part/s local computer system 442. 
[0078] As illustrated in Rgures 3 and 4, a key 



. aspect of present invention.is to capture financial.transz,. 
actions that both parties, such as parties A and B, have 
agreed upon in temis of the financial transaction data. 
This also assures that both parties are simultaneously 

5 aware of new transactions. If the transactions are fed by 
renDote booking systems, this can occur when the trans- 
action is booked. The methods and systenns for an 
embodiment of the present invention assist both parties 
in establishing reconciliation norms and then in monitor- 

10 ing the mark to martcet values with more certainty, 
reducing costly exception processing on all sides, whk^h 
is the main engine for change in this partk^ular market- 
place. 

[0079] Currentiy, the fact is that the exception 

15 processing requirements are extremely onerous on all 
parties. The methods and systems for an embodiment 
of the present invention requires little or no reprogram- 
ming of customer systems. The system for an embodi- 
ment of the present invention generates reports in an 

2o on-line mode that are available to users and that display 
key financial information that the collateral units of indi- 
vidual users can use to monitor and control their portfo- 
lios of collateralized agreements and the transactions 
covered by those agreements with a certainty that the 

25 parties are using the same formulae. 

[0080] An embodiment of the present invention pro- 
vides a global system that reduces manual activity while 
expanding productivity and acts as a bridge to any con- 
firmation system or systenns, as well as to some depos- 

30 itory systenns. Assume four parties, such as parties A, 
B, C, and D, which can all be, for example, financial 
institutions, such as, banking institutions. Most complex 
transactions, such as swap type transactions are, in 
fact, executed between two financial institutions. Party A 

35 can be one financial institution, and B can simply be a 
different financial institution. Parties B, C, and D can be, 
for example, the three largest counter-parties to A's 
interest rate swaps book. They are not restricted as to 
geography or the like. 

40 [0081] If A has collateral agreements, for example, 
with parties B, C, and D, and B has agreements, for 
example, with parties A, C, and D, and so on, there is a 
whole series of bilateral, collateral agreements k)etween 
these four parties. In an embodiment of the present 

45 invention, tiBnsactions are marked to market nightly, for 
example, within A's mainframe or A's server (or B's 
server or C's server or D*s server). Once this is com- 
pleted, they feed via a secure high volume line the 
transaction identifications and the mark to martcet val- 

50 ues for those transactions to the system for an embodi- 
ment of the present invention. 

[0082] In the aforementioned embodiments, a user 
inputs files (files that are provided by parties A, B, C, 
and D) of financial transaction details and of the mark to 
55 market values associated with those financial transac- 
tions. This can be a daily (or more frequent) data feed 
that includes an identification portion and a mark to 
market portion of the feed. The system for an embodi- 
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^ ment of the present. invention takes this feed, translates, 
the data to a common format, and then parses ft, and 
validates that, in fact, the system has reconciled the 
transaction. If the system has not reconciled the trans- 
action, the system parses rt, maps it into the language 
that the reconcilement system understands, and then 
perfonm a recondlement, for example, against client 
B's input files. 

[0083] Therefore, the system translates all of the 
financial transaction data, for example, of today's finan- 
cial transactions in standard form and goes through a 
matching routine, as opposed to a confirmation routine, 
to see, for example, if B has input B's side of this partic- 
ular transaction. Once that reconciliation process takes 
place, then, for example, for the next day's feed, the only 
infomnation the system actually parses out is the new 
mark to market value. 

[0084] In an emt>odiment of the present invention, 
the output files are, in fact, web-enabled. Effectively, 
they are portfolio reports that the system allows the cus- 
tomer to access and to see what their mark to market 
values are versus, for example, any B, or any C or D. 
and so on, and likewise, with any of the other parties. 
Thus, the parties can see what their netted value of 
portfolio transactions is versus other individual counter- 
parties. By enabling the parties to do this, they can 
determine very quickly whether or not more or less col- 
lateral is required, and whether, in fact, there is a 
change of collateral required under the terms of the col- 
lateral agreement It is extremely important in a collat- 
eral agreement to have current and accurate mark to 
market values against the collateral agreement to 
reduce risks for each of the parties, and the methods 
and systems for an embodiment of the present invention 
provide a means to reduce such risks. 
[0085] The complexities of the process are multi- 
plied by the fact that many of these financial institutions 
have what are known as global books. A global book 
means that certain transactions are booked, for exanrv 
ple, in the United States; other transactions of the same 
portfolio against B may be booked in the United King- 
dom, and still other transactions may be booked in Sin- 
gapore for, example, against Asia Pacifrc counter- 
parties. When dealing with a bilateral agreenr^nt, it 
means dealing with a netted totality of those transac- 
tions versus the same totality of any B. This requires, 
bask^lly, a 24 hour by 7 day capability, so that a finan- 
cial institution with a glottal book is always updating its 
mark to market values against a party, against the glo- 
bal book of transactions. 

[0086] Cun^ntty, all counter-parties basically deal 
on a bilateral basis, many of them on a manual basis. 
The methods and systenns for an embodiment of the 
present invention, provides a 24 hour by 7 day ptatfomn 
with a web-enabled capability of reviewing portfolios of 
mark to market values to any party anywhere in the 
world. An emt)odiment of the present invention includes, 
for example, a number of major aspects. One aspect, for 



example, is -the- matching-,and reconciliation aspect.. 

Once a transaction has been matched and reconciled in 
a transaction between parties, such as A and B, another 
aspect of an embodiment of the present invention, fo^ 

5 example, is that then the system is able to take and 
parse an updated mark to market valuation against 
those matched transactions and perform mathematical 
calculations to create a netted value against those 
transactions. Still another aspect for an embodiment of 

10 the present invention is to enable a customer to review 
and receive on-line reports of the customer's global 
portfolio. This is done at a server level, in whfeh the cli- 
ent is enabled to access the server for an embodiment 
of the present invention from their local PC and review 

15 their positions. 

[0087] Another functk)n that a party has is the abil- 
ity to export finandal transaction data on the system by 
a counter-party into another spreadsheet. A party can 
download the data into his or her booking/accounting 

20 system and generate his or her own spreadsheet The 
client appfication (e.g.. GUI) for an embodiment of the 
present invention can be programmed to take on most 
any format of spreadsheet that a party utilizes. In this 
way, a party can import their latest financial transac- 
ts tional data every morning into the system and make it 
available to any counter-party that access the system. 
[0088] Refemng now to Rgure 5, entitled "Expo- 
sure Summary Report for Bank No. 1 a sample Expo- 
sure Summary Report is provided to illustrate a report in 

30 an embodiment of the methods and systenns for collat- 
eral matching and nrtark to market reconciliation. The 
sample report represents the exposure of one party, 
represented by Bank 1, to two or more other parties, 
represent by Bank 2 and Bank 3. 

35 [0089] The exposure that Bank 1 has to the others 
is separated between those transactions that are 
matched, for instance between Bank 1 and Bank 2, and 
those that are not matched t>etween Bank 1 and Bank 2. 
Each bank's transaction values are accumulated for that 

40 portion of the portfolio that is matched and unmatched. 
The individual net sums mean that when all transactions 
are summed, keeping mind of the sign of the value 
according to that parties MTM value, the net exposure 
of Bank 1 to Bank 2 can be visually depicted. In this 

45 illustration, Bank 1 has a 21,214,590.41 total positive 
exposure to Bank 2; Bank 2 has a total negative expo- 
sure to Bank 1 of 41 ,281 ,764; and the total net exposure 
that Bank 2 has to Bank 1 is 20,087,173:59. This is 
repeated for each counter-party that Bank 1 has expo- 

50 sure to or from. 

[0090] Rgures 6A-D, entitled 'Data Table for 
Matched Rnancial Transactions," illustrate sample data 
for matched financial transactions in an embodiment of 
the methods and systems for collateral matching and 

55 mark to market reconciliation. The present invention 
matches all transactions input by each bank to the 
other. 

[0091] Rgure 6A represents the matched transac- 
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, ..tions between Bank . Vand.Bank 2..The table displays alL 
data for both banks that represent the matching criteria. 
Once a financial transaction is matched, the two sides 
of the matched transaction are given a unique identifier 
known as the "Recon Matching ID" that remains for the 5 
life of the matched transaction. Rgure 68 is a continua- 
tion of Rgure 6A so that the totals are displayed. The 
totals include the nunrtber of records and the net sum of 
the mark to market values of matched trades. 
[0092] Rgure 6C shows similar matched trades 10 
between Bank 1 and Bank 3. Rgure 6D is a continuation 
of 6C so that the totals are displayed, as in Rgure 6B. 
This particular example shows a net negative mark to 
market value from Bank 1 to Bank 3. 
[0093] Rgure 7. entitled "Data Table for Unnnatched 75 
Rnancial Transactions,' depicts an unmatched financial 
transaction table representing two parties. Bank 1 and 
Bank 2. All transaction data is displayed so that Bank 1 
can use this table as a worksheet when recondling with 
Bank 2. All transactions are viewed from the point of 20 
view of Bank 1, although the system knows that the 
counter-party for each of the transactions represented 
is Bank 2. 

[0094] Rgure 8, entitied "Data Table for Expired 
Rnancial Transactions,* illustrates sample data for 2s 
financial transactions that have expired or matured. The 
table displays all expired transaction where Bank 1 is 
one party and Bank 2 is the counter-party. The table is 
divided by those transactions denominated in United 
States Dollars (USD) and those denoted by other cur- 30 
rencies. 

[0095] Rgure 9, entitied "Import Errors Bank No. 2," 
illustrates financial transaction data submitted by one 
party. Bank 2, that failed validation checks and was sub- 
sequently rejected. Rnancial transaction data may be 35 
rejected because the data file doesnl contain certain 
required fields or because certain fields contain specific 
data fomnats. This table includes all rejecttons with the 
appropriate en^or messages. 

[0096] Rgure 10, entitied "Intemational Swaps 40 
Dealers Association (ISDA) Agreement Matrix," illus- 
trates a sample ISDA Agreement Matrix in an embodi- 
ment of the methods and systems for collateral 
matching and mark to market reconciliation. The ISDA 
is an industry managed association that creates and 45 
maintains standards for how financial transactions are 
processed by all parties. These standards are d'rfferent 
for each type of financial instrument, and likewise there 
are different standards of documentation for each type 
or class of financial transaction. so 
[0097] The ISDA Agreement Matrix shows that any 
party can have different agreements or versions of the 
agreements with different counter-parties, depending 
when the agreements were negotiated. The ISDA 
matrix serves as the baseline for the present invention 55 
to recognize the terms under which the financial trans- 
action IS processed. 

[0098] Rgure 1 1 , entitled "Sample Input Data RIes,' 



..jllustrates three sample .input data, file, formats Jn^an». 
embodiment of the methods and systems for collateral 
matching and marie to maricet reconciliation. The three 
formats include: 

• Tab Delimited 

• Rxed Rjrmat 

• Tab Delimited with Headings. 

[0099] Rgures 12A-D, entitied "Rle Import Specifi- 
cation,' represent examples of inputs that have been 
stripped from the formats provided by the inputting party 
and that are translated to the standard mark to market 
reconcilement format. 

[0100] Rgure 13, entitied "Matching Criteria," illus- 
trates a data table of matching criteria in an embodi- 
ment of the methods and systems for collateral 
matching and mark to market reconciliation. In ttiis 
embodiment, the present invention uses field matching 
criteria to match financial transactions from two or more 
parties. Some fields require exact matches, while others 
may have tolerances. For example, data that shows a 
date for party A that is one day different from the corre- 
sponding date for party B may still be considered as a 
matching date. 

[0101] There are also different levels of matching. 
I=or example, two parties may bilaterally determine a 
very lenient matching criteria that is categorized by the 
system as a "Level 3" matching criteria. In this instance 
(i.e.. Level 3), many fields require exact matches, but 
the maturity date of the transaction could be different by 
ten days for a transaction between the two parties and 
still be considered a matched trade. 
[0102] Rgures 14A and 14B, entitied "Tables of 
Data Relds," illustrate sample financial transaction data 
tables that specify the field names, the data type within 
the field, and the maximum data length of the field. 
[0103] The foregoing description and associated 
figures detail only illustrative examples of the environ- 
ment in which the invention can be used and are not 
intended to be limiting. For Instance, data fields and 
attributes can be constantly upc^ted and added by 
authorized users (e.g., parties, system administrators, 
financial service providers, etc.). Furthermore, the pro- 
gramming languages, software platfomns, operating 
systems, hardware components, communk:ations pro- 
tocols, and other technology mentioned in the foregoing 
description are by way of example only, and the present 
invention may always be enhanced to incorporate the 
most advanced availat>le technology. Variations and 
modifications of the present invention is apparent to one 
skilled in the art, and the above disclosure is intended to 
cover all such modifications and equivalents. 

Claims 

1 . A platibrm-independent method of collateral match- 
ing and mark to market reconcilement using a glo- 
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. baJ communications.network, comprising: . ^ 

accessing said global communications net- 
work; 

transmitting financial transaction data, wherein s 
said financial transaction data comprises finan- 
cial data and user instructional data; 
converting said finandal transaction data to a 
standard format; 

comparing a first set of financial transaction 10 
data with a second set of financial transaction 
data to detemnine a collateral match decision; 
retrieving mark to market parameters for said 
financial transaction data associated with said 
collateral match decision; 15 
using said mark to market parameters to calcu- 
late a market value for said financial transac- 
tion data associated with said matched 
decision; and 

providing useful reports. 20 

The method of claim 1 , wherein said mark to market 
parameters comprise at least one of the following: 

market values associated with a financial trans- 2s 
action; and 

user specified dedsion criteria for valuing said 
financial transaction; and 
user specified decision criteria for reconciling 
said financial transaction. 30 

The method of claim 2, wherein said market values 
associated with said financial transaction comprise 
real-time, worid-wide market values. 

35 

The method of claim 1 , further comprising: 

managing said financial transaction data; 

auditing said financial transaction data upon 40 
submission by a user; and 

administering said financial transaction data. 

The method of claim 1 , wherein said converting of 45 
said financial transaction data to said standard for- 
mat comprises: 

providing a template for import of said financial 
transaction data in an electrons medium; so 

importing said financial transaction data; 

creating an import spedfk^tion for said stand- 
ard format of each file; and 55 

generating a unique import specification code 
to monitor said file. 



6. The method of claim .1,, wherein said.converting,of«^ 
said financial transaction data to said standard for- 
mat comprises: 

providing a template for export of said financial 
transaction data in an electronic medium; 
exporting said financial transaction data; 
creating an export spedfk^ation for said stand- 
ard format of each file; and 
generating a unique export specrfteation code 
to monitor said file. 

7. The method of claim 1 , further comprising: 

processing said financial transaction data 
using a mark to market processor. 

8. The method of claim 1 , further comprising: 

processing said financial transaction data 
using a data conversion processor. 

9. TTie method of daim 8. wherein said data conver-- 
sion processor comprises: 

managing a data file from said user; 
converting said data file to a standard file for- 
mat; 

parsing said data file; 

validating said data file; 

converting a data field to a standard data field 

format; 

inserting a filler data field for empty-fixed data 
fields; 

mapping a standardized, populated data field 
according to said user's preferences; 
reconfiguring import specifications; 
creating new import specifications; 
reconfiguring export specifications; 
creating new export specifications; and 
logging en-ors. 

10. The method of claim 1 , further comprising: 

processing said financial transaction data 
using a recondlement processor. 

11. The method of daim 10, wherein said recondle- 
ment processor comprises: 

configuring updated data fields; 

using one or more matching algorithms for a 

set of parties associated with said finandal 

transaction; 

prioritizing matching algorithms for said set of 
parties assodated with said finandal transac- 
tion; and 

using tie-breaker rules when said matching 
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algorithm retums.more ,than one or more marr 

ket valuations for said financial transaction data 
associated with said collateral match decision. 

12. The method of claim 1 , wherein said useful reports 
comprise a report of at least one of the following: 

said collateral match decision; 
said market value; 

said real-time worid-wide market value; 
total exposure of said user; 
import en^ors for said user; 
said mark to market parameters; 
said user specified decision criteria for valuing 
said financial transaction; and 
said user specified decision criteria for recon- 
ciling said financial transaction. 

13. The method of claim 1 , further comprising: 

controlling a communications path for discuss- 
ing said financial transaction data and one or 
more assodated market valuations among 
multiple users. 

14. A platfonn-independent system of collateral match- 
ing and mark to market reconcilement using a glo- 
bal communications networic, comprising: 

means for accessing said global communk:a- 
tions network; 

means for transmitting financial transaction 
data, wherein said finandal transaction data 
comprises financial data and user instructional 
data; 

means for converting said financial transaction 
data to a standard format; 
means for comparing a first set of financial 
transaction data with a second set of financial 
transaction data to determine a collateral 
match decision; 

means for retrieving mark to market parame- 
ters for said financial transaction data associ- 
ated with said collateral match decision; 
means for using said mark to market parame- 
ters to cabulate a market value for said finan- 
cial transaction data associated with said 
matched decision; and 
means for providing useful reports. 

15. The system of claim 14, wherein said marie to mar- 
ket parameters comprise at least one of the follow- 
ing: 

maricet values associated with a financial trans- 
action; and 

user specified decision criteria for valuing said 



financial transaction; and„,- „ ^ — 

user specified decision criteria for reconciling 
said financial transaction. 



1 6. TTie system of daim 1 5, wherein said market values 
assodated with said finaru^ial transaction comprise 
real-time, worid-wide market values. 

TO 1 7. The system of daim 1 4. further comprising: 

means for managing said financial transaction 
data; 

means for auditing said finandal transaction 
15 data upon submission by a user; and 

means for administering said financial transac- 
tion data. 
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18. The system of daim 14, wherein said converting of 
said financial transaction data to said standard for- 
mat further comprises: 

means for providing a template for import of 
said financial transaction data in an electronic 
medium; 

means for importing said financial transaction 
data; 

means for creating an import specification for 
said standard format of each file; and 
means for generating a unique import spedfi- 
cation code to monitor said file. 

19. The system of claim 14, wherein said converting of 
said financial transaction data to said standard for- 
mat further comprises: 

means for providing a template for export of 
said financial transaction data in an electronk: 
medium; 

means for exporting said financial transaction 
data; 

means for creating an export spedfk^tion for 
said standard format of each file; and 
means for generating a unique export specifi- 
cation code to monitor said file. 

20. The system of daim 14, further comprising: 

means for processing said financial transaction 
data using a marie to market processor. 

21. The system of claim 14, further comprising: 

means for processing said financial transaction 
data using a data conversion processor. 

22. The system of claim 21 , wherein said data conver- 
sion processor comprises: 
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. . meai^ for managing.a.dala file from said user,_. , _ 
means for converting said data file to a stand- 
ard file fomrtat; 

means for parsing said data file; 
means for validating said data file; s 
means for converting a data field to a stanch 
data field format; 

means for inserting a filler data field for empty- 
fixed data fields; 

means for mapping a standardized, populated 10 
data field according to said user's preferences; 
means for reconfiguring import specifications; 
means for creating new import specifications; 
means for reconfiguring export specifications; 
means for creating new export speciftcations; 15 
and 

means for logging enors. 

23. The system of claim 1 4, further comprising: 

20 

nrieans for processing said financial transaction 
data using a reconcilement processor. 

24. The system of claim 23, wherein said reconcile- 
ment processor comprises: 25 

means for configuring updated data fields; 
means for using one or more matching algo- 
rithms for a set of parties associated with said 
financial transaction; 30 
means for prioritizing matching algorithms for 
said set of parties associated with said finan- 
cial transaction; and 

means for using tie-breaker rules when said 
matching algorithm returns more than one or 35 
more market valuations for said financial trans- 
action data associated with said collateral 
match decision. 

25. The system of claim 1 4, wherein said useful reports 40 
comprise a report of at least one of the following: 

said collateral match decision; 
said maricet value; 

said real-time worid-wide market value; 45 
total exposure of said user; 
import en'ors for said user; 
said mark to market paranrteters; 
said user specified dedsion criteria for valuing 
said finar^'al trartsaction; and so 
said user specified decision criteria for recon- 
ciling said financial transaction. 

26. The system of claim 14. further comprising: 

55 

means for controlling a communications path 
for discussing said financial transaction data 
and one or more associated market valuations 



24 

among multiple users. . 

27. A platform-independent autonrmted collateral 
matching and mark to market reconcilement 
method for creating, managing, verifying, and con- 
fimning matched financial transactions, comprising: 

displaying a user module for viewing, selecting, 
inputting, and transmitting transaction data 
from a user to a network collateral matching 
and reconcilement system; 
receiving said transaction data upon submis- 
sion by a user; 

translating said transaction data upon submis- 
sion by said user, 
. authentk:ating said transaction data upon sub- 
mission by said user; 

storing said transaction data upon submission 
by said user; 

associating said transaction data with collateral 
matching parameters to determine a matching 
outcome; 

using said transaction data associated with 
said matching outcome to detemnine a mark to 
market valuation; and 

transmitting said mark to market valuation to be 
displayed by said user interface. 

28. The method of claim 27, further comprising: 

auditing said transaction data upon submission 
by said user; 

controlling a communications path for discuss- 
ing said transaction data and said matching 
outcome among multiple users; and 

generating useful reports. 

29. A platfornvindependent automated collateral 
matching and mark to market reconcilement sys- 
tem for creating, managing, verifying, and confirm- 
ing matched financtal transactions, comprising: 

means for displaying a user module for viewing, 
selecting, inputting, and transmitting transac- 
tion data from a user to a network collateral 
matching and reconcilement system; 
means for receiving said tiansaction data upon 
submission by a user; 

means for translating said transaction data 

upon submission by said user; 

means for authenticating said transaction data 

upon submission by said user; 

means for storing said transaction data upon 

submission by said user; 

means for associating said transaction data 

with collateral matching parameters to deter- 
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mine a matching outcome; . . 

means for ising said transaction data associ- 
ated with said matching outcome to detemiine 
a mark to market valuation; and 
means for transmitting said mark to market val- s 
uatk)n to be displayed by said user interface. 

30. The system of claim 29, further comprising: 

means for auditing said transaction data upon io 
sutMTiission by said user; 

means for controlling a communications path 
for discussing said transaction data and said 
matching outcome among multiple users; and is 

means for generating useful reports. 

31. A secure, platform-independent automated system 

for collateral matching and mark to market recon- 20 
cilement, comprising: 

a network automated collateral matching and 
mark to market reconcilement system coupled 
to at least one communications network having 25 
a plurality of users; 

an interactive user module coupled with a net- 
work management system server connected to 
said communications network having a plurafity 
of users; 30 
a plurafity of client temninals coupled to said 
interactive user module for user interaction with 
said network automated collateral matching 
and mark to market reconcilement system. 

35 

32. The system of claim 31, wherein said interactive 
user module comprises an application that is down- 
loaded from a web-page to said network automated 
collateral matching and mark to market reconcile- 
ment system. 40 

33. The system of claim 31 , wherein said interactive 
user module is communicated to said network auto- 
mated collateral matching and mark to market rec- 
oncilement system by one of an internet, an 45 
intranet, or an extranet. 

34. The system of claim 31 , wherein said communk»- 
tions network is a financial institution's communk:a- 
tions network. so 
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Daily Transaction Reconcilement Flows 

Client Transaction Flow 

START OF DAY 



Export data to 
ASCnffle 



_ 401 



410 _ 



Monitor FTP 
server 



Enoypt using 
public key and add I 4^2 
digital signature 



As each file arrives 
411 - translate and copy 
to server 



Login to FTP 
server and transmit 
file 



412 _ 



Decrypt and 
authenticate 



- 403 



Import, update 
- and match p^rh 
file as it arrives 



T 



PERIODIC RECONCILIATION EVERY N HOURS 



420 . 



Run reconciliation 
for all participants 



421 _ 



Export results for 

each client, 
encrypt and copy 
to FTP server 



Login to FTP server and 
receive results file(s) 



440 



Decrypt and 
authenticate 



. 441 



Import results to 
MS-Access 
r^rting system or 
irk-house system 



_ 442 



FIG. 4/14 
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Exposure Summary Report for Bank No. 1 



Bank No. 2 



Matched 



OURS 



-21,590,096.77 



Unmatched 



OURS 



42,804,687.18 



Totml 



21,214,590.41 



Matched 



THEIRS 



24,548,818.00 



Unmatdied 



THEIRS 



-65,830,582.00 



Total 



-41,281,764.00 



Bank No. 3 



NET 



-20,067,173J9 



Matched 



OURS 



28,698,177.31 



Unmatched 



OURS 



20,611,853.19 



Total 



49,310,030.50 



Matched 



THEIRS 



-35,761,533.08 



Unmatched 



THEIRS 



-4,059325.65 



FIG. 5/14 



Total 



NET 



-39,820,858.73 



9,489,171.77 
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Import Errors Bank No. 2 



BANK2 



c:/derivs/imports/banlc2.tab 



AT LINE: 



135 



No data for required field Field [deal req] value Q 



NY5006-9987500-USD-25/02/97-25/08W-0-0 



BANK2 



c:/derivs^sq)0xls/bank2.tBb 



ATUNE: 



109 



No data for required field Field [deal req] value Q 



N00002S2780-1000000004;SD4)8/l>9y93-l(V09/97-<M) 



BANK2 



c:/d£rivs^iiq)oi1s/bank2.tab 



AT LINE: 



107 



No data for requfred fiidd Fidd [deal icq] value Q 



N0000205090-50000000-USD-21/07/92-23/07/97-(M) 



BANK2 



cydenvs^niports/bazik2.tab 



ATUNE: 



104 



No data for required field Field [deal req] value Q 



N00O0069866-4000000O-USD-l8A)4y91-17/12/97-(M) 



BANK2 



c:/denvs^mpoits/bank2.tab 



ATUNE: 



103 



No data for required field Field [deal req] vahie Q 



N0000069857-17000000-USD-18/04/91-17/12/97-0-0 



BANK2 



c:/d£iiva^n4>orta/baiik2.tab 



ATUNE: 



16 



No data for required field Field [deal req] value [] 



LNCF186496-20000000a-DEM-01/03/»5-03A)3/98-(W) 



BANK2 



ci/deii vs/nnports/baiik2 . tab 



ATUNE: 



13 



No data for required field Field [deal req] vahie Q 



L000013233-25000000OP-04/1 1/94-04/1 1/97-0-0 



BANK2 



c:/dcrivs/iiDports/baiik2.tab 



AT LINE: 



12 



No data for required field Fidd [notional 1] vahie Q 



FRA-USEKnn-04JSD-18/12/96-18/12/99-196933-0 



BANK2 I cyderivs^nqxirts/bank2.tab 



ATUNE: 



11 



No data for required fidd Held [notional 1] value Q 



COM010082-0-USDu06/06W-06/06/00-14401W) 



FIG. 9/14 
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International Swap Dealer Association (ISDA) Agreement Matrix 





Products 


AMARUS30AA1 


MGTCUS33XXX 


TSCOGB22AA1 


XMARUS30AA1 


IRS,XCY 


XX 


ISDA87 


ISDA92 






XX 


19880621 


19930101 






XX 


A 


A 




FRA 


XX 


BBAIR 








XX 


19871201 








XX 


A 




MGTCUS33XXX 




ISDA87 


XX 


ISDA92 






19880621 


XX 


19960505 






B 


XX 


A 






BBAIR 


XX 


BBAIR 






19871201 


XX 


19871201 






A 


XX 


A 


TSCOGB22AA1 




ISDA92 


ISDA92 


XX 






19930101 


19950101 


XX 






B 


B 


XX 



FIG. 10/14 
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Sample Input Data FDes - Three (3) Types of In^Kit Format 



4)172 



Tabdelinited- BANKIE 
GB600 8900001464 

319576188905499 
(3600 8900001464 

S ITL 

104163960 
(3600 8900001464 

B ITL 

11755169264581.8 19866 
(3600 8900001464 

SWAP SNO 

20000000-2000000011594203-1 1 12029 
(3600 8900001464 8002725754 
SWAP SmC 3012 
1500OOOO.15OO00008695652 -1806968 
CS600 8900001464 8002725754 
SWAPSNG 3011 
10000000-100000006959911 352298.1 



BANK3 

09/11/94 09/11/99 
38805817574 14723073 0 92 
41172 BANK3 

15A)5/97 20A»6/97 
17603^ 0 0 

4U72 BANK3 

19/06/97 ywim 

822861.9 10874440.48 

8002725754 BANK3 
3012 DEM 

142920.2 ( 
BANK3 
DEM 
281333.4 
BANK3 
CHP 
32191.75 



14943 13022EQ INDEX OPTIONS 3359 
19400000 

1497135 190EQ INDEX OPTIONS 3386 
-17603500000 

0 

1497170392EQ INDEX OPTIONS 3387 
19866000000 

LGNDGH (SWAF) 389300002 
DEM 27/10/89 30/10/98 31 AO/89 30^098 

0 

LONDON (SWAP) 390183004 
DEM 02/07/90 05/07/00 05/07/90 QSOTjOO 

0 

LONDON (SWAP) 392022006 
CHF 22A)l/92 26A>l/98 24/01/92 2601^ 
384489.8 



Fix RmsBtf- BANKIN 

1195SW12 0393174024 EUROP NYBANK2 COMPANY CTS 0100042228 

0000616303 BANX2(X»MP>^ -N EUROP 8000886971 0000616303 SWPSC3012 

DKKDKK 100000000.00 -100000000.0014997226.00 -406435.58 07.JUL-97 06/23/1993 06/23/1993 
06^3/1998 06/23/1998 

1195SW12 0393288023 EUROP NYBANK2 COMPAHY CTS 0100042228 

0000616303 BANK2C0MP/WY LO EUROP 8000803804 0000616303 SWPSaOl 1 

ITL ITL 25000000000.00 -25000000000.00 14651930X1485344.27 07/JUL-97 10/15/1993 10/19/1993 

10^9/2000 10/19/2000 

1195SW12 0394012035 EUROP NYBANK2 COMPANY CTS 0100042228 

0000616303 BANK2(X»MPANY LO EUROP 8000803804 0000616303 SWPSC301 1 

FRF FRF 750000000.00 -750000000.00 127026066.18 4997872.96 07-JUL-97 01/12/1994 01/13/1994 
01/13/1999 01/13/1999 

1195SW12 0394034032 EUROP NYBANK2 COMP/WY CTS 0100042228 

0000616303 BANK200MPANY-N EUROP 8000886971 0000616303 SWPSC3012 

FRFFRF 100000000.00 -100000000.00 16936808.82 -441474.27 07-;UL-97 02A)3/1994 02/04/1994 
02A>4/1998 02A>4A998 

1 195SW12 0394039053 EUROP NY BANK2 COMPANY CTS 0100042228 

000616303 BANK2 COMPANY LO EUROP 8000803804 0000616303 SWPSC3011 

DEM DEM 100000000.00 -100000000.0057110220.19 4583895JK9 07-JUL-97 02A)8/]994 02/10/1994 
02/10/19994 02/10/1999 



Tftb DcUndted viitfa hejMfngt - BANia 



TmuKtioD ID 


Notional 


Ccy 


TnasMCtioa 


Date 


MAtvity Date DEAL REQ 


44513 


10000000000 


JPY 


14/11/95 


lS/II/99 


212820 


0 




44514 


10000000000 


JPY 


14/11/95 


15/U/99 


5059420 


0 




18163 


100000000 


CHF 


02/10/96 


06/10/99 


1430964 


0 




186644 


25000000 


DEM 


23/06/95 


23/06A>0 


67183 


0 




186704 


100000000 


DEM 


07/08/95 


07/08/99 


3153 


0 




187152 


100000000 


DEM 


23/D9/96 


13/02/98 


-4155335 


0 




187171 


100000000 


CHF 


03/10/96 


07/10/99 


1294263 


0 




187177 


150000000 


CHF 


04/10/96 


07/10/99 


1541463 


0 




187194 


200000000 


CHF 


15/10/96 


15/10/97 


224S009 


0 




COM010082 


0 


ua> 


06/06/97 


06A)6/D0 


1444019 


0 




FRA-USD-OTl 


0 


USD 


18/12/96 


18/12/99 


196933 


0 




L000013233 


25000000 


GBP 


04/11/94 


04/11/97 


0 


0 




L000044507 


5000000000 


. JPY 


13/06/96 


17/12/99 


-77367 


0 




LOOO 187481 


50000000000 


ITL 


31/05/96 


04/06/99 


-6035 


0 




LNCFl 86496 


200000000 


DEM 


01/03/95 


03/03^ 


0 


0 




LNSW0035313 


150000000 


SK 


07/09/94 


09/09/97 


-1994031 


0 




LNSW016798 


50000000 


DEM 


27/05/92 


l5A)7/97 


-1982180 


0 




LNSW016863 


50000000 


DEM 


27/05/92 


15/07/02 


-3351200 


0 




LNSW023285 


100000000 


DKK 


23A)6/93 


23/06/98 


1132865 


0 




LNSW026045 


25000000000 


ITL 


15/10/93 


19/10/00 


•1345684 


0 




LNSW028079 


750000000 


FRF 


12/01/94 


13/OlW 


-4898807 


0 




LNSW028815 


100000000 


FRF 


03/02/94 


04/02/98 


440713 


0 




LNSW028953 


100000000 


DEM 


08/02/94 


10/02/04 


-3779613 


0 




LNSW029037 


50000000000 


ITL 


10/02/94 


14/02/98 


227029 


0 


FIG. 


LNSW032838 


250000000 


SEK 


15/06/94 


17/06W 


3091420 


0 



INITIAL REQ 
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FILE IMPORT SPECIFICATION 



Bank Bank No. 1 Specification BANKIE c:/derives/miports/bankle.txt 



Input Field 


Type 


Fonhat 


Re*qd. 


Position 


LcBflth 


Map Table 


Output Field 


Defeuh 


BIC 


fixed 




Yes 


0 


0 




BIC 


BANKl 


client class 


text 




No 


1 


0 








coimteiparty 


text 




Yes 


2 


0 


MapCP 


cpBIC 




counterparty 


text 




Yes 


2 


0 




iiqnitCP 




account id 


text 




No 


3 


0 








account id nam 


text 




No 


4 


0 








transaction id 


text 




Yes 


5 


0 




transaction id 




InputProduct 


text 




Yes 


6 


0 




InputProduct 




transaction type 


text 




Yes 


6 


0 


MapProduct 


Product 




product code 


number 




No 


7 


0 








buy sell ind 


text 




No 


8 


0 




Buy_SeU 




ccyl 


text 




Yes 


9 


0 




PayCcy 




ccy2 


text 




Yes 


10 


0 




RecCcy 


[Ccyl] 


trade date 


date 


dd/mm^yy 


Yes 


11 


0 




trade date 




settle date 


date 


dd/imn/yy 


Yes 


12 


0 




settle date 




start date 


date 


dd^sxm/yy 


Yes 


13 


0 




start date 


[tiade_dat 


maturity _date 


date 


dd/iTwrtAyy 


Yes 


14 


0 




matuiity_date 




security id 


text 




No 


15 


0 








notionall 


number 




Yes 


16 


0 




PayNotional 




notional2 


number 




Yes 


17 


0 




RecNotional 


[notionall] 


notional 


number 




No 


18 


0 








mark to market 


number 




Yes 


19 


0 




MTM 




Strike Prices 


number 




No 


20 


0 




Strike Price 





FIG. 12A/14 
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FILE IMPORT SPECIFICATION 



Bank Bank No. 1 Specification BANK IN cyderivesfa^its/banklatxt 



Input Field 


Type 


FonxBt 


Re'qd. 


Position 


Length 


Table 


Output Ficki 


De&ult 


BIC 


fixed 




Yes 


0 


0 




BIC 


BANKl 


transaction id 


text 




Yes 


18 


16 




transaction id 




PaientTians actio 


ta± 




No 


60 


16 




ParentID 




inputCP 


text 




Yes 


181 


10 


MapCP 


cpBIC 




inputCP 


text 




Yes 


181 


10 




inputCP 




tnputProduct 


text 




Yes 


191 


16 


MapFroduct 


Ptoduct 




InputPioduct 


text 




Yes 


191 


16 




InputProduct 




Buy/Sen 


text 




No 


202 






Buy Sen 




call_put 


text 




No 


204 


1 




can_put 




Strike Price 


number 




No 


207 


20 




Strike Price 




ccyl 


text 




Yes 


243 


3 




Payccy 




ccy2 


text 




Yes 


247 


3 




Rccccy 


[ccyl] 


notionall 


number 




Yes 


256 


20 




PayNotional 




notionalZ 


number 




Yes 


276 


20 




RecNotional 




notionalUSD 


number 




No 


296 


19 




NotionalBase 




MTM 


number 




Yes 


315 


20 




MTM 




MTMdate 


date 


dd/nn^yy 


Yes 


335 


10 




MTMdate 




trade date 


date 


mm/dd/yyyy 


Yes 


345 


11 




trade date 




start date 


date 


mm^dd/yyyy 


No 


357 


11 




start date 




maturity date 


date 


mnydd/yyyy 


Yes 


369 


12 




matnritydate 




settlement date 


date 


mm^dd/yyyy 


Yes 


381 


11 




settle date 





FIG. 12B/14 
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FILE IMPORT SPECIFICATION 



Bank Bank No. 2 Specification BANK2 c7derives/iinports/bank2.tab 



loput Field 


Type 


Format 


Re'qd. 


Positton 


Length 


Map 
Table 


Output Field 


I>e&ult 


cpBIC 


fixed 




No 


0 


0 




cpBlC 


BANKl 


Product 


fixed 




No 


0 


0 




Product 


OTHER 


BIC 


fixed 




No 


0 


0 




BIC 


BANK2 


trmvsaction id 


text 




Yes 


1 


0 




transaction id 




notionall 


fluoxibef 




Yes 


2 


0 




Paynotional 




ccyl 


text 




Yes 


3 


0 




Payccy 




tisnsactton 
date 


date 


dd/mni^^ 


Yes 


4 


0 




trade__date 




maturitydate 


date 


dd/noQ^y 


Yes 


5 


0 




maturity date 




deal req 


number 




Yes 


6 


0 




KfTM 





FIG. 12C/14 
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FILE IMPORT SPECIFICATION 



Bank Bank No. 3 Specification BANK3 c:/derives/imports/baiik3.txt 



input rieio 


type 


Format 




Position 


T Ktllllll 


map iooie 








fixed 




Yes 


0 


0 




buy sell 




cpBIC 


fixed 




Yes 


0 


0 




cpBIC 


BANKl 


BIC 


fixed 




Yes 


0 


0 




BIC 


BANK3 


SIC system id 


text 




No 


1 


0 








book id 


text 




No 


2 


0 








trade id 


text 




Yes 


3 


0 




transaction id 




ticket id 


text 




No 


4 


0 








ins type 


text 




Yes 


5 


0 


MapProduct 


Product 




iiis_type 


text 




Yes 


5 


0 




inputProduct 




rec notional 


number 




Yes 


7 


0 




Paynotional 




rec notional ccy 


text 




Yes 


13 


0 




PayCcy 




trade date 


date 


dd/mm/yy 


Yes 


14 


0 




trade date 




iDaturity_date 


date 


dd/mm/yy 


Yes 


15 


0 




maturity date 




business date 


dale 


dd/mm/yy 


Yes 


16 


0 




MTMdate 




base mtm 


number 




No 


17 


0 




MTM 




other ccy 


text 




Yes 


30 


0 




Recccy 


[rec^notio 


other notional 


number 




Yes 


31 


0 




RecNotional 


[rec notio 


put call 


text 




No 


34 


0 


MapCodes 


call put 




buysell 


text 




No 


35 


0 


MapCodes 


buy sell 




effective date 


date 


dd/nur/yy 


No 


37 


0 




start date 
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Matching Criteria 

Level external 



Order 


Bcldl 


Field2 


Type 


Tolerance 


•Hype 


Specia] 




Wue2 


1 


BIC 


cpHIC 


text 


0 










2 


cpBIC 




tcA 


0 










3 


QdemalMatchlD 


BIC 


teil 


0 











Level M 



Older 


F£kll 


Field2 


Type 


Tolerance 


Tlype 


Special 


^^el 




1 


BIC 


cpBIC 














2 


cpBIC 


BIC 


tai 












3 


Product 




tCJl 












4 


PayCcy 
















5 


RecCcy 




teA 












6 


PaynotionaJ 




number 












7 


Recnotional 




number 












8 


natuiity date 




date 


5 


d 








9 


trade date 




date 


1 


d 








10 


buy sen 




text 


0 




A 


B 


S 


11 


call_put 




text 


0 




B 






Level levell 


Older 


Field 1 


Field2 


Type 


Tolerance 


Ttype 


Special 


Vatuel 


Vahid 


1 


BIC 


cpBIC 














2 


CpBIC 


mc 


tGtt 












3 


Product 




te^ 












4 


PayCcy 




ten 












5 


RecCcy 




text 












6 


PayNotkmal 




nuiober 












7 


RecNotional 




nuiii>er 












8 


maturity date 




date 


5 


d 








Level leveE 


Older 


Fieldl 


FiBld2 


Type 


Tolezancie 


Tlypc 


Specia] 


Vahiel 


Vaiad 


1 


BIC 


cpBIC 


teitt 












2 


cpBIC 


BIC 


tea. 












3 


Product 




text 












4 


PayCcy 




tejft 












5 


RecCcy 




ten 












6 


PayNotional 




nuni>er 












7 


RecNotional 




nurober 












Level leveB 


Older 


Fcldl 


Feld2 


Type 


Tolerance 


Ttype 


Special 


Vduel 


Vahie2 




BIC 


cpBIC 


ten 


0 










2 


cpBlC 


BIC 


ten 


0 










3 


Product 




ten 


0 










4 


PayCty 




ten 


0 










5 


PayNotional 




number 


0 










6 


trade date 




date 


0 










7 


naturity date 




date 


10 


d 
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Tables of Data Fields 



Trades Tables 



Name 




Length 


IfSTOortOode 

111 iLnjt kv^rVUb 


Text 


10 


BIC 


Text 


12 


q)BIC 


Text 


12 


TrmirtPP 


Text 


50 


narpTTtll 1 

u^U CI 1 1. 1 1 ■# 


L CAl 


15 


u cu laa^iLiiA HI 


Text 


20 


l4}_Ua[lodCUQIl_KI 


1CA,1 


90 






fl 

o 




XCAl 


IS 




ICAl 


J 


X gyn o iiona i 




Q 
o 




Text 


s 


XVCvl^ U llUIioA 


I^IIIIIIPCT 


fi 
o 






Q 
o 




Date/Time 


g 


Start Dflte 


xyaiM X III ig 


g 


Maturity Date 


Date/Time 


8 r 


settle date 


Date/Time 


8 


Call Put 


Text 


5 


Buy_Sell 


Text 


5 


Strike Price 


Number 


8 


MatchCode 


Text 


15 


Matchmunber 


Number (Long) 


4 


ManualMatch 


Yes/No 


2 


ExtermlMatchld 


Text 


25 


ManualLink 


Nunto* (Long) 


4 


MTM 


Number 


8 


MTMdate 


Date/Time 


8 


reconflag 


Yes/No 


1 


%diff 


Number 


8 


absdiff 


Number 


8 


status 


Number 


2 


created 


£>at&Time 


8 


la5t_iq>dated 


Date/Time 


8 
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Tables of Data Fields 

Import Specificatioiu 


Name 


Type 


Length 


Import^eSpecs 






ImportCode 


Tort 


10 


BIC 


Text 


10 


Desciiptuio 


Text 


50 


fikpath 


Text 


50 


type 


Text 


10 


ddimitcx 


Text 


2 




Number (Integer) 


2 


eof 


Text 


50 


ontputtypc 


Text 


5 


table 


Text 


50 


Active 


YeaWo 


1 




Name 


Type 


Length 


ImportFtddSpecs 






ImpoTtcode 


Text 


10 


ifield 


Text 


50 


itype 


Text 


10 


ifiormat 


Tent 


25 


irequiml 


Yes/No 


1 


ikcy 


Yes^o 


1 


ikeyno 


Number (hither) 


2 


ikeyid 


Text 


10 




Number (Integer) 


2 


ifieldcn 


Number (Integer) 


2 


imaptable 


Text 


75 


ofidd 


Text 


50 


ofbrmat 


Text 


50 


dc&ultvahie 


Text 


50 


comments 


Text 


255 


Map TaMcs 


Name 


Type 


Length 


MapCP 






Importcode 


Text 


10 


toputvahie 


Text 


50 


outputvaluc 


Text 


10 


MapProduct 






tnqMrtcode 


Text 


10 


inpotvahie 


Text 


50 


outputvaluc 


Text 


10 


Match Criteria 


Name 


Type 


Length 


MatcfaCodes 






MatchCode 


Text 


25 


MatcfaOrder 


Number (Int^cr) 


2 


Fiddl 


Text 


50 


ridd2 


Text 


50 


FiddType 


Text 


10 


Tolerance 


Number 


8 


ToIType 


Text 


10 


Special 


Text 


10 


Valuel 


Text 


50 


Vahae2 


Text 


50 
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